Medical device location authorization

ABSTRACT

Certain examples provide systems, methods, and apparatus for medical device management. An example method includes determining a role mapping for a user and determining a location mapping for the user. The example method includes generating a combined location and role mapping for the user based on the role mapping and the location mapping. The example method includes configuring user access to one or more medical devices based on the combined location and role mapping. The example method includes facilitating interaction with the one or more medical devices according to the configured user access.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application relates and claims priority to U.S. ProvisionalPatent Application Ser. No. 62/259,932, filed on Nov. 25, 2015, which isherein incorporated by reference in its entirety for all purposes.

FIELD

The present disclosure relates generally to medical devices. Morespecifically, the present disclosure relates to methods, systems, andapparatus to provide location authorization and access control formedical devices.

BACKGROUND

Increasingly, medical devices are becoming electronic or involve anelectronic or software component. Electronic devices, distributedfacilities, and scattered patients make training, treatment, andtroubleshooting difficult. Further, it is often difficult to educate thepublic, and patients may not seek the treatment they should due to alack of information and access. Operators and administrators may alsointroduce inefficiencies in their operation and management of medicaldevices due to a lack of information and access. Additionally,unauthorized access has potential to introduce harmful error as well asinefficiency into patient treatment.

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 illustrates an example hospital deployment location structure.

FIG. 2 illustrates an example ward deployment.

FIG. 3 illustrates an example mapping of user role and permittedfunctionality.

FIG. 4 illustrates an example role mapping architecture or system toconfigure, store, and implement a mapping of roles to user(s) and/orgroup(s) of users.

FIG. 5 illustrates an example location mapping architecture or system toconfigure, store, and implement a mapping of locations to user(s) and/orgroup(s) of users.

FIG. 6 illustrates an example role and location mapping schema toconfigure and govern user access to medical device systems at variouslocations.

FIG. 7 illustrates a flow diagram for location and role-basedauthorization of action at a medical device.

FIG. 8 depicts a data flow diagram for system configuration of role andlocation mapping.

FIGS. 9A-9C illustrate example user interfaces to configure a user groupname.

FIGS. 10A-10C illustrate example user interfaces to configure a usergroup name.

FIG. 11 depicts a data flow diagram for location authorization of a userwith respect to a medical device at a location.

FIGS. 12A-12B illustrate example user interfaces for medical devicemonitoring.

FIG. 13 is a block diagram of an example medical device monitoring andcontrol system.

FIG. 14 is a block diagram of an example processor system that can beused to pump, implement, control and/or drive the systems and methodsdescribed herein.

The foregoing summary, as well as the following detailed description ofcertain embodiments of the present invention, will be better understoodwhen read in conjunction with the appended drawings. For the purpose ofillustrating the invention, certain embodiments are shown in thedrawings. It should be understood, however, that the present inventionis not limited to the arrangements and instrumentality shown in theattached drawings.

DESCRIPTION OF CERTAIN EXAMPLES

Certain examples are shown in the above-identified figures and describedin detail below. In describing these examples, like or identicalreference numbers are used to identify the same or similar elements. Thefigures are not necessarily to scale and certain features and certainviews of the figures may be shown exaggerated in scale or in schematicfor clarity and/or conciseness. Additionally, several examples have beendescribed throughout this specification. Any features from any examplemay be included with, a replacement for, or otherwise combined withother features from other examples.

It will be understood that the present invention may be embodied inother specific forms without departing from the spirit thereof. Thepresent examples and embodiments, therefore, are to be considered in allrespects as illustrative and not restrictive, and the invention is notto be limited to the details presented herein.

Although the following discloses example methods, apparatus, systems,and articles of manufacture including, among other components, firmwareand/or software executed on hardware, it should be noted that suchmethods, apparatus, systems and articles of manufacture are merelyillustrative and should not be considered as limiting. For example, itis contemplated that any or all of these firmware, hardware, and/orsoftware components could be embodied exclusively in hardware,exclusively in software, exclusively in firmware, or in any combinationof hardware, software, and/or firmware. Accordingly, while the followingdescribes example methods, apparatus, systems, and/or articles ofmanufacture, the examples provided are not the only way(s) to implementsuch methods, apparatus, systems, and/or articles of manufacture.

When introducing elements of various embodiments of the presentdisclosure, the articles “a,” “an,” “the,” and “said” are intended tomean that there are one or more of the elements. The terms “comprising,”“including,” and “having” are intended to be inclusive and mean thatthere may be additional elements other than the listed elements.

When any of the appended claims are read to cover a purely softwareand/or firmware implementation, at least one of the elements is herebyexpressly defined to include a tangible medium such as a memory, adigital video disc (DVD), compact disc (CD), BLU-RAY™, etc. storing thesoftware and/or firmware.

Certain examples facilitate management of medical devices includingblood collection or apheresis devices, infusion pumps, drug deliverypumps, and/or other medical devices. For example, an infusion pumpinfuses fluids, medication, or nutrients into a patient. An infusionpump can be used intravenously, subcutaneously, arterially, and/orepidurally, for example. For example, an infusion pump can administerinjections at a variety of rates (e.g., injections too small for anintravenous (IV) drip (e.g., 0.1 mL per hour), injections per minute,injections with repeated boluses, patient-controlled injections up tomaximum number per hour, or injections of fluids whose volumes vary bytime of day, etc.).

In certain examples, an operator (e.g., a technician, nurse, etc.)provides input regarding type of infusion, mode, and/or other deviceparameter. For example, continuous infusion provides small pulses ofinfusion (e.g., between 500 nanoliters and 10 milliliters), with a pulserate based on a programmed infusion speed. Intermittent infusionalternates between a high infusion rate and a low infusion rate withtiming programmable to keep a cannula open, for example.Patient-controlled infusion provides on-demand infusion with apreprogrammed ceiling to avoid patient intoxication. The infusion rateis controlled by a pressure pad or button that can be activated by thepatient, for example. Infusion pumps can include large volume pumps(e.g., for nutrient solution delivery to feed a patient), small-volumepumps (e.g., for medicine delivery), etc.

In certain examples, an operator or administrator may configure amedical device, such as an infusion pump, apheresis device, etc., and/orset one or more parameters for interaction between the device and adomain controller and/or a provider data management system. Certainexamples provide flexibility in facilitating operator and/oradministrator (e.g., user) operation and configuration of a medicaldevice while maintaining device reliability and secure through newauthorization protocols and systems.

Certain examples provide location authorization preventing a user fromaccessing data and performing actions in locations other thanlocation(s) at which the user has been authorized to act. By addinglocation authorization to a medical device authorization protocol, amedical device data management system (such as the Fenwal DXT™ datamanagement system manufactured by Fenwal™, a Fresenius Kabi company)provides application level end-to-end security control to protectlocation data, application function, patient safety, etc. Userpermission is assigned depending on not only a functional role of theuser but also a location assignment for the user as maintained by thedata management system. Thus, data management systems can interact withmedical devices (e.g., Fenwal Amicus™, Alyx™, Autopheresis-™ and Aurora™Apheresis systems, other apheresis devices, Fresenius Kabi Agilia® pump,Optima™ pump, Pilot™ pump, other drug delivery pump, etc.) for flexible,remote configuration and operation while helping to ensure data andconfiguration safety and security, for example.

In certain examples, a role-based authorization mechanism defines a usertype, function, or role (e.g., system engineer, technician, nurse,physician, administrator, etc.) as well as a location (e.g., aparticular healthcare facility, healthcare organization, city, employer,etc.) and user (e.g., a user account or profile that associates the userwith a defined role, etc.). Thus, if a user has an account and theaccount identifies him or her as a member of the system engineeringgroup, then that user can access to all resources that system engineershave (pending location limitations, etc.).

Using a location authorization schema, a logical structure of ahealthcare organization (e.g., a hospital deployment structure withindividual pumps, etc.) is incorporated into a user authorization systemso that a user is assigned a specific role (e.g., a pharmacist inhospital A in Highmountain Healthcare, a pharmacist in a particularward, etc.) and also restricted to a specific location (e.g., allpharmacist group access but only in Hospital A, not at Hospital B or C).Thus, the location and role-based user authorization provides a greatergranularity to restrict people at a location even though the users havecertain privileges from their assigned roles.

FIG. 1 illustrates an example hospital deployment location structure 100including a health organization 102 including a plurality of hospitals104, 106, 108 under its umbrella. Each hospital A 104, B 106, and C 108includes one or more pumps and/or other medical devices 110, 112, 114with electronic configuration and operation ability.

The deployment location structure 100 provides information about thelogical structure of the organization 102 in which a data managementsystem (e.g., Fenwal DXT™, etc.) is installed. In certain examples,deployment locations can be categorized into the following types:Organization, Hospital, Ward, etc. In such examples, the organizationlocation represents the overall healthcare organization 102 in which thedata management system is being deployed.

The hospital location represents a single hospital 104, 106, 108 thatbelongs to the Organization 102. In certain examples, the ward locationrepresents a single ward location that belongs to a hospital location.

FIG. 2 illustrates an example ward deployment 200. The example warddeployment 200 of FIG. 2 includes a health organization 202 including aplurality of hospitals 204, 206, 208 under its umbrella. Each hospital A204, B 206, and C 208 includes a plurality of wards 210-222, and eachward 210-222 includes one or more pumps and/or other medical devices224-236 with electronic configuration and operation ability. As shown inthe example of FIG. 2, health organization 202 includes Hospital A 204,Hospital B 206, and Hospital C 208. Hospital A 204 includes Ward AA 210,Ward AB 212, and Ward AC 214. Hospital B 206 includes Ward BA 216 andWard BB 218. Hospital C 208 includes Ward CA 220 and Ward CB 222. Asshown in the example of FIG. 2, each Ward 210-222 has a plurality ofnetworked pumps 224-236 for operator configuration and operation.

FIG. 3 illustrates an example mapping 300 of user role and permittedfunctionality for a medical device pump example. As shown in the exampleof FIG. 3, user roles include administrator, biomedical engineer,pharmacist, pharmacy technician, business analyst, nurse, etc. Theexample of FIG. 3 also lists functionality relating to the pump device,such as monitor pump status, abort data set distribution, data setdistribution report, create data set distribution policy, data setupload, infusion data reporting, etc. For each use role, the mapping 300provides which functionality is available to a user in the particularrole. Thus, as shown in the example of FIG. 3, an administrator is ableto monitor pump status, abort data set distribution, view/generate adata set distribution report, create a data set distribution policy,upload a data set, view/generate an infusion data report, etc. Abiomedical engineer, however, cannot upload a data set but can accessthe remaining functionality, while the pharmacist and business analystare allowed access to all pump and reporting functionality in theexample mapping 300. A pharmacy technician, however, is only allowed tomonitor pump status, view/generate a data set distribution report, andview/generate an infusion data report, not abort data set distribution,create data set distribution policy, or upload a data set. According tothe example mapping 300, a nurse may only view/generate an infusion datareport.

Certain examples provide an authorization model for human users thatuses Role and Location Mapping mechanisms to assign permissions to usersdepending on their functional role and location assignment in thesystem, regardless if the user accesses the data management systemdirectly from a user interface and/or through an external system (e.g.,Vigilant DrugLib, etc.). For example, when both role and locationmapping have been configured, a user who wants to schedule a Datasetdistribution in Hospital ABC must be authorized to be a Pharmacist whobelongs to Hospital ABC location.

Certain examples provide an architecture to facilitate interactionbetween the data management system and a domain controller. The domaincontroller defines groups and users, and the data management system mapsgroups and users to roles and specifies locations using the domaincontroller information. The architecture provides and/or uses a mappingto cross-reference locations from the data management system to anactive directory of the domain controller. Employees/users are assignedto certain location to prevent users from improperly accessinginformation and/or functionality at other locations. Assignment of auser/group for location is similar to assigning a role to a user and/orgroup of users as described above.

Thus, mapping dictates user interaction with a medical device (e.g., apump, apheresis device, etc.) at a given location. For example, if auser has pharmacist privileges at one location, he or she can onlydistribute a drug library to the pumps at that location for which he orshe has authorization.

FIG. 4 illustrates an example role mapping architecture or system 400 toconfigure, store, and implement a mapping of roles to user(s) and/orgroup(s) of users. The role mapping architecture 400 enables anAdministrator and/or automated system to configure mapping of rolesprovided by a data management system 402 (e.g., Pharmacist, BiomedicalEngineer, Administrator, etc.) to groups of users defined within adomain controller 404 (e.g., Active Directory) of a deploymentinformation technology (IT) infrastructure.

As shown in the example of FIG. 4, the data management system 402defines a plurality of roles such as administrator 406, pharmacist 408,and biomedical engineer 410. Each role 406, 408, 410 is associated withone or more device functions, such as configure instrument 412,configure system 414, upload dataset 416, schedule distribution 418,monitor distribution 420, etc. For example, the administrator 406 canconfigure the instrument 412 and configure the system 414. Thepharmacist 408 can upload a dataset 416, schedule distribution 418, andmonitor distribution 420, for example. The biomedical engineer 410 canschedule distribution 418 and monitor distribution 420, for example.

The domain controller 404 defines a plurality of user groups such as anadministrator user groups such as administrator group (e.g., DXTADMIN)422, pharmacist group (e.g., DXTPHRM) 424, and biomedical group(DXTBMED) 426. One or more users are associated with each group 422,424, 426. For example, in the example of FIG. 4, user001 and user002 arepart of the administrator group 422. User003 and user004 are part of thepharmacist group 424. User004 and user005 are part of the biomedicalgroup 426.

As illustrated in the example system 400 the role 406, 408, 410 (e.g.Administrator, Pharmacist, Biomedical Engineer, etc.) and itscorresponding function permissions 412-420 are predefined by apermission roles mapping 428. For example, when the mapping 428 betweendomain controller DXTPHRM user group 424 and Pharmacist role 408 hasbeen configured, any user who belongs to DXTPHRM group 424 is able touse all functions (e.g., upload dataset 416, schedule datasetdistribution 418, monitor dataset distribution 420, etc.) permitted toPharmacist role 408 by the data management system 402.

FIG. 5 illustrates an example location mapping architecture or system500 to configure, store, and implement a mapping of locations to user(s)and/or group(s) of users. The location mapping architecture 500 enablesan Administrator and/or automated system to configure mapping oflocations defined within the data management system 402 (e.g. Lake Bluffsite, Memphis site, Knoxville site, etc.) to the defined groups of userswithin the domain controller 404 (e.g. Active Directory) of thedeployment IT infrastructure (e.g., Lake Bluff Employees, location 2employees, location 3 employees, etc.).

For example, the data management system 402 defines and/or storesinformation for a plurality of facility 506 locations. In the example ofFIG. 5, locations are broken up by region, such as a North region 508and a South region 510. Within each region 508, 510 individual citiesand/or other sub-regions can be identified. For example, the Northregion 508 for organization OrgA 506 may include a Lake Bluff location512. The South region 510 in the example of FIG. 5 may include Memphis514 and Knoxville 516 locations.

As shown in the example of FIG. 5, the domain controller 404 alsodefines and/or stores information for a plurality of user groups 518,520, 522 by location. For example, user groups may include a Lake Bluffemployees group 518, a location 2 users group (e.g., DXTLOC2) 520, alocation 3 users group (e.g., DXTLOC3) 522, etc. As shown in the exampleof FIG. 5, user001 and user002 may belong to the Lake Bluff employeesgroup 518; user003 and user004 belong to location 2 user group 520; anduser004 and user005 belong to the location 3 user group 522. A locationmapping 524 stores the relationship between user group 518, 520, 522 andlocation 506, 508, 510, 512, 514, 517. The mapping 524 can tie a group(e.g., Lake Bluff employees 518) to a single location (e.g., LakeBluff), to a region (e.g., DXTLOC2 520 to South 510), and/or to anentire network (e.g., DXTLOC3 522 to OrgA 506), for example.

The locations 506-516 and their mapping 524 to domain controller groups518-522 is defined during system configuration and, in some examples,can be updated dynamically based on changes in employment, location,rule, etc. For example, when a mapping between domain controller DXTLOC2group 520 and DXT South location 510 has been configured, any user whobelongs to DXTLOC2 group 520 can access all information for the Southlocation 510.

FIG. 6 illustrates an example role and location mapping schema 600 toconfigure and govern user access to medical device systems at variouslocations. As shown in the example of FIG. 6, the role mapping 428 fromthe example of FIG. 4 and the location mapping 524 from the example ofFIG. 5 are combined with employee information 602 from a selected group(e.g., Lake Bluff employees 518 from the example of FIG. 5) to form arole and location mapping 604. For example, the role mapping 428provides an association between user groups and roles, as well asfunction(s) accessible to the roles. The location mapping 524 provides acorrelation between user groups and locations. Thus, a given user hasboth a role and a location, and a combined role and location mapping 604can be formed by correlating roles and locations according to anemployee group list 602. Using the combined role and location mapping604, the Administrator 406, Pharmacist 408, and Biomedical Engineer 410can access all information and use all functions 412-420 (e.g., scheduleDataset distribution, monitor Dataset distribution, upload Dataset,configure system, configure instrument, etc.) permitted to theirrespective role for the Lake Bluff location 512 only.

FIG. 7 illustrates a flow diagram 700 for location and role-basedauthorization of action at a medical device. At block 702, a locationand role mapping is determined. For example, as described above withrespect to FIG. 4, available role(s) and associated capability(-ies) areidentified and mapped to one or more users and/or user groups via thedata management system 402 and domain controller 404. The role mapping428 provides guidance to the data management system 402 to govern accessto medical devices in communication with and/or controlled by the datamanagement system 402. Additionally, as described above with respect toFIG. 5, the location mapping 524 is generated by evaluating availablelocations (e.g., network, region, city, etc.) and associating usersand/or user groups with the available locations. The role mapping 428and location mapping 524 are combined with employee/user information 602to form the role and location mapping 604 for particular users havingparticular roles at particular locations.

At block 704, a particular user is identified. For example, a particularuser logs in and is identified as a pharmacist in the pharmacy group 424associated with the pharmacy role 408 and in the Lake Bluff employees518 group authorized at the Lake Bluff location 512.

At block 706, the data management system 402 and domain controller 404configure access for that user based on the mapping 604 associated withthe user. For example, based on the determination of which location(s)and which function(s) the user is permitted to access based on his orher role, the data management system 402 and/or the domain controller404 configure functionality available to the user when he or she logs inand/or otherwise accesses a medical device, user interface, workstation,etc., at a particular location.

At block 708, the data management system 402 facilitates interactionwith one or more connected medical devices (e.g., infusion pump,apheresis device, etc.) based on the configured access. For example, thedata management system 402 can provide the access configuration to aparticular device for the specific user. The user can then interact withthe medical device (e.g., the pump, the apheresis device, theworkstation, etc.) according to allowed configuration for that user.

FIG. 8 depicts a data flow diagram 800 for system configuration of roleand location mapping. The data flow diagram 800 provides further detailfor certain examples of block 702 of the example process 700 describedabove. At block 802, configuration begins. At block 804, a role isselected. For example, a role 805 (e.g., Administrator, Nurse,Biomedical Engineer, Pharmacist, Pharmacy Technician, Business Analyst,etc.) is selected from a plurality of options and/or specified to thedomain controller 404 and/or data management system 402. Block 804 canbe repeated for a plurality of roles.

At block 806 a user group is configured for the role 805. For example,FIG. 9A illustrates an example user interface 900 to configure a usergroup name (e.g., DXTBMED) for a biomedical engineer role 805, and FIG.9B illustrates an example user interface 950 to configure a user groupname (e.g., DXTPHRM) for a pharmacist role 805. An example interfacesuch as interface 970 of FIG. 9C displays the configured user groupname(s) 807 for the role(s) 805. The group 807 information is used toform a role mapping 428.

At block 810, a hospital and/or other health location is selected. Forexample, a hospital 811 is selected from a plurality of options and/orspecified to the domain controller 404 and/or data management system402. Block 810 can be repeated for a plurality of hospitals. At block812, a user group name is configured for the hospital 811 (e.g., GeriHospital A1). Block 812 can be repeated for additional hospital(s)(e.g., Geri Hospital B1, etc.). For example, FIG. 10A illustrates anexample user interface 1000 to configure a user group name (e.g.,Geri_Hospital A1) for a first hospital location, and FIG. 10Billustrates an example user interface 1050 to configure a user groupname (e.g., Geri_Hospital B1) for a second hospital location. An exampleinterface such as interface 1070 of FIG. 10C displays the configureduser group name(s) 813 for the hospital(s) 811. The group 813information is used to form a location mapping 524. The location mapping524 can be combined with the role mapping 428 to form a location androle mapping for one or more users, for example.

FIG. 11 depicts a data flow diagram 1100 for location authorization of auser with respect to a medical device at a location. The data flowdiagram 1100 provides further detail for certain examples of block 706of the example process 700 described above. At block 1102, monitoringbegins. A user name 1103 is provided. For example, the user name 1103can be input, retrieved from a database, scanned from a barcode, radiofrequency identifier (RFID), determined from a photograph, etc. At block1104, the user group name is read for monitoring. For example, based onthe user name 1103 and a user group name 807 retrieved from the rolemapping with user group permissions 428, a user group name is providedand combined with the user name 1105 for verification.

At block 1106, the user name is evaluated with respect to the identifieduser group to verify whether the user name is in the user group. Forexample, the user name 1103 is combined to a list associated with theuser group 807 to determine whether or not the user is in the specifiedgroup. If the user name is not found in the user group, then, at block1108, the user is labeled as an unauthorized user. If the user islabeled as an unauthorized user, the user may be blocked from accessingthe system, may be flagged or reported, may be warned, may be promptedto enter different and/or additional information, etc.

However, if the user name 1103 is verified as a member of the user group807, then a location of desired user access 1107 is provided and, atblock 1110, the user group name 807 is read for the accessed location1107. The user group name 807 and location 1107 are combined with usergroup name(s) for location 813 provided by the location mapping 524.Then, at block 1112, the user name and group name(s) 1111 for thelocation 1107 are verified to determine whether the user name is in theuser group for the location.

If the user name is not found in the user group, then, at block 1114, adevice interface is launched without including medical device(s) (e.g.,pump(s), apheresis device(s), etc.) in the location 1107. However, ifthe user name is authenticated as being in the user group, then, atblock 1116, a device user interface is launched which includes medicaldevice(s) (e.g., pump(s), apheresis device(s), etc.) at the location1107.

For example, a biomedical engineer configured in the Geri_Hospital A1has proper permissions to monitor pumps in the Geri_Hospital A1hospital. FIG. 12A illustrates an example user interface 1200 includingpumps for which the biomedical engineer has authorization to monitor atthe Geri_Hospital A1. The biomedical engineer launches DXT UI 1200 andthen selects Devices from the Navigational panel on the left. Theexample user interface 1200 shows the pump in the Geri_Hospital A1hospital, but the pumps in other hospitals are not shown on the screen1200.

FIG. 12B illustrates an example user interface 1250 including pumps forwhich an administrator has authorization to monitor in the Geri_Org1organization. An administrator configured in the Geri_Org1 organizationhas the permissions to monitor all pumps in the organization, so theexample interface 1250 shows all three pumps in the organization andtheir locations (e.g., Geri_Hospital A1, Geri_Hospital B1, andGeri_Hospital C1). The administrator launches DXT UI 1250 then selectsDevices from the Navigational panel on the left. The example userinterface 1250 shows the pumps in all hospitals in the Geri_Org1organization.

FIG. 13 is a block diagram of an example medical device monitoring andcontrol system 1300. The example system 1300 includes a role mapper1310, a location mapper 1320, and an access controller 1330communicating with one or more medical devices 1340-1344. The examplesystem 1300 can be implemented in accordance with the systems andmethods described above with respect to FIGS. 1-12B, for example.

The example role mapper 1310 uses user group information from a usergroup database 1350 in conjunction with role information from a roledatabase 1352 and maps user(s)/group(s) to role(s). Additionally, therole mapper 1310 uses information from a functionality database 1354 todetermine what device 1340-1344 is available to which role and,therefore, to which user(s)/user group(s).

The example location mapper 1320 uses user group information from theuser group database 1350 in conjunction with location information from alocation database 1356 and maps user(s)/group(s) to location(s).

The access controller 1330 takes role mapping information from the rolemapper 1320 and location mapping information from the location mapper1320 to generate a role and location mapping configuration controllingwhich user(s) and/or user group(s) have access to which functionalityfor one or more medical devices 1340-1344 at one or more locations. Asdescribed in more detail above with respect to FIGS. 1-12A, the accesscontroller 1330 restricts and/or permits information and functionalitydisplayed on a user interface associated with one or more medicaldevices 1340-1344 and can customize display and device interaction for auser, for example.

FIG. 14 is a block diagram of an example processor platform 1400 capableof executing the instructions of FIGS. 7-8, and 11 to implement theexample systems and interfaces of FIGS. 1-6, 9A-9C, 10A-10C,12A-12B, and13. The processor platform 1400 can be, for example, a server, apersonal computer, a mobile device (e.g., a cell phone, a smart phone, atablet such as an iPad™), a personal digital assistant (PDA), anInternet appliance, a DVD player, a CD player, a digital video recorder,a Blu-ray player, a gaming console, a personal video recorder, a set topbox, or any other type of computing device.

The processor platform 1400 of the illustrated example includes aprocessor 1412. The processor 1412 of the illustrated example ishardware. For example, the processor 1412 can be implemented by one ormore integrated circuits, logic circuits, microprocessors or controllersfrom any desired family or manufacturer. In the illustrated example, theprocessor 1412 is structured to include the example role mapper 1310,the example location mapper 1320, and the example access controller 1330of the example system 1300.

The processor 1412 of the illustrated example includes a local memory1413 (e.g., a cache). The processor 1412 of the illustrated example isin communication with a main memory including a volatile memory 1414 anda non-volatile memory 1416 via a bus 1418. The volatile memory 1414 maybe implemented by Synchronous Dynamic Random Access Memory (SDRAM),Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory(RDRAM) and/or any other type of random access memory device. Thenon-volatile memory 1416 may be implemented by flash memory and/or anyother desired type of memory device. Access to the main memory 1414,1416 is controlled by a memory controller.

The processor platform 1400 of the illustrated example also includes aninterface circuit 1420. The interface circuit 1420 may be implemented byany type of interface standard, such as an Ethernet interface, auniversal serial bus (USB), and/or a PCI express interface.

In the illustrated example, one or more input devices 1422 are connectedto the interface circuit 1420. The input device(s) 1422 permit(s) a userto enter data and commands into the processor 1412. The input device(s)can be implemented by, for example, an audio sensor, a microphone, acamera (still or video), a keyboard, a button, a mouse, a touchscreen, atrack-pad, a trackball, isopoint and/or a voice recognition system.

One or more output devices 1424 are also connected to the interfacecircuit 1420 of the illustrated example. The output devices 1424 can beimplemented, for example, by display devices (e.g., a light emittingdiode (LED), an organic light emitting diode (OLED), a liquid crystaldisplay, a cathode ray tube display (CRT), a touchscreen, a tactileoutput device, a printer and/or speakers). The interface circuit 1420 ofthe illustrated example, thus, typically includes a graphics drivercard, a graphics driver chip or a graphics driver processor.

The interface circuit 1420 of the illustrated example also includes acommunication device such as a transmitter, a receiver, a transceiver, amodem and/or network interface card to facilitate exchange of data withexternal machines (e.g., computing devices of any kind) via a network1426 (e.g., an Ethernet connection, a digital subscriber line (DSL), atelephone line, coaxial cable, a cellular telephone system, etc.).

The processor platform 1400 of the illustrated example also includes oneor more mass storage devices 1428 for storing software and/or data.Examples of such mass storage devices 1428 include floppy disk drives,hard drive disks, compact disk drives, Blu-ray disk drives, RAIDsystems, and digital versatile disk (DVD) drives.

Coded instructions 1432 representing the flow diagrams of FIGS. 7-8, and11 may be stored in the mass storage device 1428, in the volatile memory1414, in the non-volatile memory 1416, and/or on a removable tangiblecomputer readable storage medium such as a CD or DVD.

From the foregoing, it will be appreciated that examples have beendisclosed which allow access to, configure of, and control of one ormore medical devices to vary automatically based on user, group, role,and/or location. Such access control can be dynamically and/orautomatically determined. Access control information can be used togenerate and/or otherwise customize medical device user interfaces forparticular user(s) and/or group(s) of user(s) based on role, location,etc.

Certain examples facilitate determination of employee group membership.User decides what group the person belongs to. In certain examples,personnel roles are configured to map to organizational structure, whichis mapped to enable and/or disable access to hardware, software,firmware, and/or other resources. Using such mapping, each person can beanalyzed according to his or her role and organizational structure.Using external active directory system and domain control providesflexibility to organize users in an organization regardless ofapplication. Rather than creating a special group with certain users orembedded users and access in a directory in the application itself, amapping can be provided between role and group without creating a newrole and/or new group and without affecting the active directory systemto move users around. In certain examples, roles and groups can becreated separately and linked dynamically. For example, an applicationprovider can define a biomedical engineering role, and a hospital candefine a biomedical engineering group. The hospital's installation andactive directory system can map the role to the group dynamically.Access is determined based on the linkage, and the medical device datamanagement system then determines what functionality is and is notavailable to the user(s) identified as biomedical engineering (e.g., bycommunicating from the medical device data management system to theactive directory and connected devices using the Windows™.NET API,etc.).

Certain examples provide computer-implemented methods for medical devicemanagement. An example method includes determining, using at least oneprocessor, a role mapping for a user based on a user account including auser role and functionality available to the user role; determining,using the at least one processor, a location mapping for the user basedon the user account and a location available to the user account;generating, using the at least one processor, a combined location androle mapping for the user based on the role mapping and the locationmapping, the combined location and role mapping providing allowedfunctionality at an allowed location for the user; configuring, usingthe at least one processor, user access to one or more medical devicesbased on the combined location and role mapping; and facilitating, usingthe at least one processor, interaction with the one or more medicaldevices according to the configured user access.

In certain examples, configuring user access further includes generatinga user interface for the one or more medical devices based on thecombined location and role mapping for the user. In certain examples,the one or more medical devices include one or more drug deliverydevices. In certain examples, the one or more drug delivery devicesinclude one or more infusion pumps.

In certain examples, determining a role mapping includes an analysis ofone or more roles with respect to the user, the one or more rolesincluding one or more of administrator, pharmacist, or technician. Incertain examples, determining a location mapping includes an analysis ofone or more locations with respect to the user, the one or morelocations including one or more of a region, a city, or a hospital. Incertain examples, the method further includes determining one or moreuser groups to which the user belongs.

Certain examples provide a tangible computer readable storage mediumincluding program code for execution by a processor. When executed, theprogram code is to implement a method for medical device management. Theexample method includes determining a role mapping for a user based on auser account including a user role and functionality available to theuser role; determining a location mapping for the user based on the useraccount and a location available to the user account; generating acombined location and role mapping for the user based on the rolemapping and the location mapping, the combined location and role mappingproviding allowed functionality at an allowed location for the user;configuring user access to one or more medical devices based on thecombined location and role mapping; and facilitating interaction withthe one or more medical devices according to the configured user access.

In certain examples, configuring user access further includes generatinga user interface for the one or more medical devices based on thecombined location and role mapping for the user. In certain examples,the one or more medical devices include one or more drug deliverydevices. In certain examples, the one or more drug delivery devicesinclude one or more infusion pumps.

In certain examples, determining a role mapping includes an analysis ofone or more roles with respect to the user, the one or more rolesincluding one or more of administrator, pharmacist, or technician. Incertain examples, determining a location mapping includes an analysis ofone or more locations with respect to the user, the one or morelocations including one or more of a region, a city, or a hospital.

Certain examples provide a system including a processor and a memory.The example processor and memory are particularly configured toimplement at least a role mapper, a location mapper, and an accesscontroller. The example role mapper is configured to determine a rolemapping for a user based on a user account including a user role andfunctionality available to the user role. The example location mapper isconfigured to determine a location mapping for the user based on theuser account and a location available to the user account. The exampleaccess controller is configured to: generate a combined location androle mapping for the user based on the role mapping and the locationmapping, the combined location and role mapping providing allowedfunctionality at an allowed location for the user; configure user accessto one or more medical devices based on the combined location and rolemapping; and facilitate interaction with the one or more medical devicesaccording to the configured user access.

In certain examples, configuring user access further includes generatinga user interface for the one or more medical devices based on thecombined location and role mapping for the user. In certain examples,the one or more medical devices include one or more drug deliverydevices. In certain examples, the one or more drug delivery devicesinclude one or more infusion pumps.

In certain examples, determining a role mapping includes an analysis ofone or more roles with respect to the user, the one or more rolesincluding one or more of administrator, pharmacist, or technician. Incertain examples, determining a location mapping includes an analysis ofone or more locations with respect to the user, the one or morelocations including one or more of a region, a city, or a hospital. Incertain examples, the user belongs to one or more user groups.

Although certain example methods, apparatus and articles of manufacturehave been disclosed herein, the scope of coverage of this patent is notlimited thereto. On the contrary, this patent covers all methods,apparatus and articles of manufacture fairly falling within the scope ofthe claims of this patent. While particular embodiments of the inventionhave been shown and described, it will be obvious to those skilled inthe art that changes and modifications may be made therein withoutdeparting from the invention in its broader aspects.

1. A computer-implemented method for medical device management, saidmethod comprising: determining, using at least one processor, a rolemapping for a user based on a user account including a user role andfunctionality available to the user role; determining, using the atleast one processor, a location mapping for the user based on the useraccount and a location available to the user account; generating, usingthe at least one processor, a combined location and role mapping for theuser based on the role mapping and the location mapping, the combinedlocation and role mapping providing allowed functionality at an allowedlocation for the user; configuring, using the at least one processor,user access to one or more medical devices based on the combinedlocation and role mapping; and facilitating, using the at least oneprocessor, interaction with the one or more medical devices according tothe configured user access.
 2. The method of claim 1, whereinconfiguring user access further includes generating a user interface forthe one or more medical devices based on the combined location and rolemapping for the user.
 3. The method of claim 1, wherein the one or moremedical devices include one or more drug delivery devices.
 4. The methodof claim 3, wherein the one or more drug delivery devices include one ormore infusion pumps.
 5. The method of claim 1, wherein determining arole mapping includes an analysis of one or more roles with respect tothe user, the one or more roles including one or more of administrator,pharmacist, or technician.
 6. The method of claim 1, wherein determininga location mapping includes an analysis of one or more locations withrespect to the user, the one or more locations including one or more ofa region, a city, or a hospital.
 7. The method of claim 1, furtherincluding determining one or more user groups to which the user belongs.8. A tangible computer readable storage medium including program codefor execution by a processor, the program code, when executed, toimplement a method for medical device management, said methodcomprising: determining a role mapping for a user based on a useraccount including a user role and functionality available to the userrole; determining a location mapping for the user based on the useraccount and a location available to the user account; generating acombined location and role mapping for the user based on the rolemapping and the location mapping, the combined location and role mappingproviding allowed functionality at an allowed location for the user;configuring user access to one or more medical devices based on thecombined location and role mapping; and facilitating interaction withthe one or more medical devices according to the configured user access.9. The computer readable storage medium of claim 8, wherein configuringuser access further includes generating a user interface for the one ormore medical devices based on the combined location and role mapping forthe user.
 10. The computer readable storage medium of claim 8, whereinthe one or more medical devices include one or more drug deliverydevices.
 11. The computer readable storage medium of claim 10, whereinthe one or more drug delivery devices include one or more infusionpumps.
 12. The computer readable storage medium of claim 8, whereindetermining a role mapping includes an analysis of one or more roleswith respect to the user, the one or more roles including one or more ofadministrator, pharmacist, or technician.
 13. The computer readablestorage medium of claim 8, wherein determining a location mappingincludes an analysis of one or more locations with respect to the user,the one or more locations including one or more of a region, a city, ora hospital.
 14. A system comprising: a processor and a memory configuredto implement at least: a role mapper configured to determine a rolemapping for a user based on a user account including a user role andfunctionality available to the user role; a location mapper configuredto determine a location mapping for the user based on the user accountand a location available to the user account; and an access controllerconfigured to: generate a combined location and role mapping for theuser based on the role mapping and the location mapping, the combinedlocation and role mapping providing allowed functionality at an allowedlocation for the user; configure user access to one or more medicaldevices based on the combined location and role mapping; and facilitateinteraction with the one or more medical devices according to theconfigured user access.
 15. The system of claim 14, wherein configuringuser access further includes generating a user interface for the one ormore medical devices based on the combined location and role mapping forthe user.
 16. The system of claim 14, wherein the one or more medicaldevices include one or more drug delivery devices.
 17. The system ofclaim 16, wherein the one or more drug delivery devices include one ormore infusion pumps.
 18. The system of claim 14, wherein determining arole mapping includes an analysis of one or more roles with respect tothe user, the one or more roles including one or more of administrator,pharmacist, or technician.
 19. The system of claim 14, whereindetermining a location mapping includes an analysis of one or morelocations with respect to the user, the one or more locations includingone or more of a region, a city, or a hospital.
 20. The system of claim14, wherein the user belongs to one or more user groups.